home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Mar 91 / MacApp.Tech$ 3⁄1⁄91 / 3122-Re[2] > MA3 opinion-Feb91 < prev    next >
Encoding:
Text File  |  1991-04-01  |  3.6 KB  |  77 lines  |  [TEXT/GEOL]
  1. Item    7419470                         27-Feb-91        17:59PST
  2.  
  3. From:   SATORI                          Satori SW, Hugh Rogovy,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    Re: RE>> MA3 opinion
  10.  
  11. James,
  12.  
  13. In a reply to my link, you state:
  14.  
  15. >>I am confused.
  16.  
  17. Don't be confused.
  18.  
  19. Making a change to a superclass many times will affect the behaviour of
  20. subclasses.  This doesn't seem to happen as much with something like the
  21. toolbox, because it contains(mostly) independent, stand-alone
  22. procedures...there is no inheritance of behaviour.  There are far less
  23. interrelations between Toolbox procedures than there are between inherited
  24. methods in OP.
  25.  
  26. The problem comes when superclass changes cause a negative behaviour change in
  27. a subclass.  Many superclass modifications that caused negative behaviour
  28. changes can be seen in TechNote #280.  A specific example (of many) are the
  29. modifications to TView focusing and visiblility methods.  These changes
  30. resulted in *numerous* changes to the TView descendents in MacApp...and even
  31. more changes to TView descendents in our four apps.
  32.  
  33. Luckily, drastic design changes such as the above-mentioned are the exception
  34. rather than the rule. But, for as long as the MacApp team continues to come up
  35. with better ways to implement superclasses and accompanying methods (which I
  36. hope they continue to do forever...), there can be the problem of superclass
  37. modifications causing negative changes to subclass behaviour. Sometimes, these
  38. behaviour changes are not apparent until a user performs "some ridiculously
  39. stupid sequence of operations that should never have been affected by the MA
  40. change anyway...".  In the real world, this causes a shipping app to drop back
  41. to beta status...meaning that we "get" to go through an extensive re-testing
  42. process to get the app back to shipping status...no fun.  Our other option is
  43. to use a non-supported and fewer feature version of MacApp on all current and
  44. future apps (we have a large in-house class/utility library that is MacApp
  45. dependent).
  46.  
  47. >>If so, I am eager to see your evidence, as such evidence would also refute
  48. >>that the claim the OOP code is more maintainable than that derived from
  49. >>structured programming.
  50.  
  51. I'm not interested in refuting anyone's claims...I just think that for as long
  52. as there are changes being made to superclasses, subclasses will find their
  53. behaviours changing in strange and wonderful (and sometimes not so wonderful)
  54. ways.  Procedural libraries (ie. the Toolbox) do not have this problem to such
  55. a great extent due to the usual lack of interdependence between procedures.
  56.  
  57. I do believe in the OOP way if life and most of the claims that go along with
  58. it.  I believe O-O *code* is more maintainable...I think it can be argued that
  59. O-O *libraries* are more difficult to maintain.  Library maintainers (ie. the
  60. MacApp team) have a very difficult job... when it comes time for library
  61. modifications they have to make an attempt to imagine every possible way
  62. (within reason) that I may have extended their framework.  App maintainers (ie.
  63. you and me) have the benefit of access to *all* of the code their app is built
  64. of.
  65.  
  66. An O-O library can be maintained...If your cards do fall right, design and code
  67. changes will have no effect or positive effects upon the behaviour of
  68. subclasses.  This is what I would like to see happen in the future with MacApp.
  69. I don't know how this can be accomplished, but I feel that I and others could
  70. benefit if Apple looked into finding a way to make MacApp updates less of a
  71. headache.
  72.  
  73.  
  74.  
  75. Chris Le Croy
  76.  
  77.